The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
A “multi-tenant storage system” (MTSS) is a storage system that includes storage resources allocated to multiple “tenants.” Each tenant is a computer system that uses the MTSS for storing data for computer system's use. A multi-tenant storage system is particularly useful in the cloud computing environment, where compute resources are allocated or re-allocated based on the demands of each computer system. To achieve greater resource utilization, shared storage resource pools are utilized on an MTSS, from which storage resources are allocated to multiple client computer systems that may be part of the cloud computing environment.
Accordingly, the MTSS receives and services input/output (I/O) data requests for storage resources from more than one computer system. The I/O requests may contain commands to the MTSS to read or write data into storage resources. These received I/O requests are assumed to be authenticated within the issuing computer systems prior to sending the I/O requests to the MTSS. For example, once an I/O request enters the computer system operating system kernel, the I/O request is implicitly trusted because some other entity (e.g., an application or the file system) is expected to have verified the I/O requester's identity and the integrity of the request contents. Thus, the MTSS may not further verify the I/O requests or the identities of the client computer systems initiating the I/O requests.
However, if a client computer system of an MTSS is compromised, then the authentication relied upon by the MTSS is compromised as well. The client computer system may then send tampered I/O requests to the MTSS, and the MTSS, without further authenticating the requests, may service the tampered I/O requests causing corruption of stored data addressed in the I/O requests.
In shared storage systems, such as an MTSS, there is also an enhanced risk of a compromised client computer system affecting storage resources that are allocated to other client computer systems. Since the MTSS has storage resources provisioned to different client computer systems, a malicious I/O request may be tampered to be directed to another client computer system's provisioned storage resources. Once the MTSS services such a request, the other computer system's data may be corrupted, and the other computer system may also get infected and compromised through the corrupted data.
For restricting access to the appropriate storage of the MTSS, “LUN masking” and “zoning” approaches may be used. “LUN masking” refers to the MTSS hiding/masking some storage resources (LUNs) between tenant computer systems. Zoning restricts groups of client computers from interacting with one another by subdividing and thus, isolating their data I/O request path to the MTSS. Both LUN masking and zoning use either IP addresses or World Wide Names (WWNs) for identifying client computer systems and the storage resources on the network. Both forms of identification are easy to spoof. Moreover, some implementations of LUN masking rely on a client computer system to “behave well” and “ignore” the storage resources that are not provisioned for the client computer system. Furthermore, LUN masking and zoning also imply that the entire storage pool is not available to all hosts—a form of physical isolation that is not ideal for resource utilization and re-allocation typical for the cloud environment.